Single Radio Voice Call Continuity (SR-VCC) has been standardized in 3GPP TS 23.216, version 9.2.0: Single Radio Voice Call Continuity (SRVCC); Stage 2, to provide continuity when a single radio capable User Equipment (UE) moves from E-UTRAN/HSPA (Evolved UMTS Terrestrial Radio Access Network/High Speed Packet Access) to UTRAN/GERAN (UMTS Terrestrial Radio Access Network/GSM EDGE Radio Access Network) while engaged in a voice call established over IP Multimedia Subsystem (IMS).
In this specification, only the E-UTRAN/HSPA to UTRAN/GERAN direction is addressed.
How to perform subsequent handovers in the reverse direction (“handback”) was studied at the time, and a solution was proposed in 3GPP TS 23.216, version 1.1.0: Single Radio Voice Call Continuity (SRVCC); Stage 2. But it then got subsequently removed from the specification.
For a reverse SRVCC (rSRVCC) from UTRAN/GERAN to E-UTRAN/HSPA to succeed for a given voice call based on the solution studied, a number of prerequisites are needed.
One example is the anchoring of the call in an IMS application server called SCC AS (Session Continuity Control Application Server) at its establishment: the studied solution reuses the Service Continuity mechanisms defined in 3GPP TS 23.237, version 9.4.0: IP Multimedia Subsystem (IMS) Service Continuity; Stage 2, which assume that the sessions that can be transferred between accesses are routed through IMS and through the SCC AS at the time of their establishment. The source access network (i.e. the RNS or BSS) needs to distinguish between calls anchored in the SCC AS and calls which have not been anchored before triggering the rSRVCC procedure. How this should be done was one of the main open issues that remained unsolved in 3GPP TS 23.216, version 1.1.0.
Other prerequisites for triggering of the rSRVCC procedure include the CS core network knowledge of UE's rSRVCC capability or the UE's IMS registration status, and need to be taken into account as well.
FIG. 1 represents how a call flow for subsequent SRVCC handback from UTRAN or GERAN with DTM/PSHO support to E-UTRAN, including the handling of the non-voice component, looked like in the solution that was briefly documented in 3GPP TS 23.216 v1.1.0, before being removed from the subsequent versions of TS 23.216.
In step S1, the source RNS decides to trigger a handover to E-UTRAN based on UE measurement reports.
In step S2, the source RNS initiates PS relocation.
Step S2 comprises an operation S2a of sending, from the source RNS, a Relocation Required (Source to Target Transparent Container) message to source SGSN (Serving GPRS Support Node).
Step S2 comprises an operation S2b of sending, from the source SGSN, a Forward Relocation Request message to the target MME (Mobility Management Entity) including information about the non-voice component only.
In step S3, the source RNS initiates CS relocation. Step S3 is performed in parallel to step S2.
Step S3 comprises an operation S3a of sending, from the source RNS, a Relocation Required (Source to Target Transparent Container) message to the source MSC (Mobile Switching Centre).
Step S3 comprises an operation S3b of sending, from source MSC, a Prepare Subsequent HO Request to the MSC Server.
Step S3 comprises an operation S3c of sending, from the MSC Server, a Forward Relocation Request (Source to Target Transparent Container) message to the target MME.
In step S4, the target MME synchronises the two Forward Relocation Request messages and requests resource allocation for the non-voice component only by exchanging Handover Request/Acknowledge messages with the target E-UTRAN.
In step S5, the target MME acknowledges the prepared CS relocation towards the source access.
Step S5 comprises an operation S5a of sending, from the target MME, a Forward Relocation Response (Target to Source Transparent Container) message to the MSC Server.
Step S5 comprises an operation S5b of sending, from the MSC Server, a Prepare Subsequent HO Response to the source MSC.
Step S5 comprises an operation S5c of sending, from the source MSC, a Relocation Required Acknowledge (Target to Source Transparent Container) message to the source RNS.
In step S6, the target MME acknowledges the prepared PS relocation towards the source access. Step S6 is performed in parallel to step S5.
Step S6 comprises an operation S6a of sending, from the target MME, a Forward Relocation Response (Target to Source Transparent Container) message to the source SGSN.
Step S6 comprises an operation S6b of sending, from the source SGSN, a Relocation Required Acknowledge (Target to Source Transparent Container) message to the source RNS.
In step S7, the source RNS synchronises the two Relocation Required Acknowledge messages and sends a Handover from UTRAN Command message to the UE.
In step S8, UE re-tunes to E-UTRAN radio and sends a Handover to E-UTRAN Complete message to the E-UTRAN.
In step S9, the target E-UTRAN informs the target MME by sending a Handover Notify message.
In step S10, the target MME completes the CS relocation.
Step S10 comprises an operation S10a of sending, from the target MME, a Forward Relocation Complete message to the MSC Server. MSC Server acknowledges the information by sending a Forward Relocation Complete Acknowledge message to the source MME.
Step S10 comprises an operation S10b of sending, from the MSC Server, a Handover Complete message to the source MSC.
In step S11, the target MME completes the PS relocation. Step S11 is performed in parallel to step S10.
Step S11 comprises an operation of exchanging, between the target MME and the source SGSN, Forward Relocation Complete/Acknowledge messages.
Step S11 further comprises an operation of performing, at the target MME, the Update bearer procedure with the Serving GW and the PDN GW. At this point the relocation of all non-voice PS bearers is completed and the user data are flowing across E-UTRAN access in both directions.
In step S12, UE performs a TAU procedure if required (e.g. due to UE mobility under CS coverage).
Subsequently, in step S13, UE initiates the Session Transfer procedure e.g. by sending a SIP INVITE (VDI) message to the VCC application. Standard IMS Service Continuity procedures are applied for execution of the Session Transfer, as described in 3GPP TS 23.237, version 9.4.0: IP Multimedia Subsystem (IMS) Service Continuity; Stage 2, and in 3GPP TS 23.292, version 9.4.0: IP Multimedia Subsystem (IMS) centralized services; Stage 2. As part of this procedure the remote end is updated with the SDP of the IMS access leg. The downlink flow of VoIP packets is switched towards the PDN GW at this point.
In step S14, the IMS triggers a network-initiated dedicated bearer for the voice component.
In step S15, the IMS releases the CS access leg which result in release of resources in the MSC Server.
In this solution, the RNS is the entity that decides whether the UE should report measurement on neighbouring E-UTRAN cells, and, in case those measurements prove to be good enough, to handover the UE to E-UTRAN. For it to make such a decision, it needs to be sure that the procedure, if initiated, can succeed. For that to be true, several prerequisites exist.
The UE is supposed to perform a number of actions throughout the procedure. That means there exists an rSRVCC capability that needs to be supported by the UE. UEs which do not support the rSRVCC capability must not be requested by the network to perform measurements on neighbouring E-UTRAN cells for the purpose of rSRVCC.
In step S13 described above, the signaling that takes place for the downlink flow of VoIP packets to be switched to the PDN GW is the sending of an INVITE message from the UE to the SCC AS. That INVITE message contains an identity which allows the SCC AS to correlate it with the previously established voice call. At the reception of this INVITE message, the SCC AS will update the remote end with the new connection information (IP address, ports) from/to which the media will be received/need to be sent.
Step S13 is described with further detail referring to FIG. 2.
In step S101, the UE initiates registration with IMS (if not already registered in IMS). Step S101 is performed when the UE determines a need for Access Transfer.
Subsequently, the UE initiates an IMS originated session toward the SCC AS using a STI to establish an Access Leg via PS access and requests Access Transfer of the IMS session that is using CS media to PS access. The statically configured STI is used if no dynamically assigned STI has been provided to the UE during session establishment.
In step S102, standard procedures are used at S-CSCF for routing of the INVITE to the SCC AS.
In step S103, the SCC AS performs the Access Transfer by updating the Remote Leg with connection information of the newly established Access Leg.
In step S104, the source Access Leg which is the Access leg previously established over CS is subsequently released.
The PS-CS Access Transfer procedure described in FIG. 2 assumes that an SCC AS exists in the IMS domain that can accept that INVITE message, and correlate it with the call that was previously established on the UTRAN/GERAN side. That boils down to two more prerequisites. Firstly, the call have to be routed through (or “anchored at”) an SCC AS. Secondly, the user has to be authorized for rSRVCC.
Last, before sending an INVITE message the UE needs to be registered to IMS. Even though this could be performed by the UE as part of the rSRVCC procedure on the fly (e.g. between step S12 and step S13), performing an IMS registration is time consuming, and having the UE register to IMS in the middle of the handover would incur an important additional delay which would impact the user experience in a negative way (long speech interruption). The IMS registration state of the UE is therefore also an aspect that should be taken into consideration in the decision making process for initiating rSRVCC to E-UTRAN. Note though that while the previously mentioned prerequisites are mandatory, an rSRVCC to E-UTRAN could succeed without this last one.
Embodiments of the present invention will improve the situation. In particular, embodiments of the present invention will propose a set of mechanisms for providing the network with the capability to discriminate the calls which meet the prerequisites for successful rSRVCC to E-UTRAN/HSPA. Such mechanisms are required in the context of the aforementioned solution, and could also be in the context of other solutions for rSRVCC to E-UTRANHSPA yet to be defined.